perm filename HIC[NEW,LSP] blob
sn#409515 filedate 1979-01-11 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00117 ENDMK
C⊗;
Date: 9 JAN 1979 0105-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
Presumable the line "SKIPA R,[STTYW1&ZZ]" just after SLINMODE:
should be "SKIPA R,[STTYW1&ZZX]"; ie. it should mask with ZZX like
all the other lines near it.
∨
Date: 8 JAN 1979 2245-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
EVAL-WHEN should not have an ARGS property.
∨
Date: 7 JAN 1979 0304-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC
Doing (TRACE $DEFRULE) in a fresh MACSYMA fails because it appears that
LISP is using the built-in AUTOLOAD handler when it should of course
be using the current one.
∨
Date: 5 JAN 1979 1549-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-10 version
To: (BUG LISP) at MIT-MC
JCL reader doesn't understand aboutt PPN specifications in the
lisp init file.
∨
Date: 5 Jan 1979 1353-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: {[foo]<bar>[ztesch] ...}
To: hic at MIT-MC, gls at MIT-MC
This bug appears to be due to the splicing macro:
(setsyntax 135 'splicing '(lambda () ()))
which *somehow* causes an untyi to be done on > (!!!) (i.e. a 76).
Looking at how the chars in the buffer look at the time it is:
[foo]
<bar
> [zt
so thatt possibly the byte pointer has gotten off by 1 word? and is seeing
the > and not the _? I'm afraid the reader + the splicing macro handlers are
too hairy for me to debug. Maybe when Quux is here?
-rpg-
∨
Date: 4 Jan 1979 1354-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: SAIL-NEWIO
To: bug-lisp at MIT-MC
I've come across a strange diskio bug in SAIL-NEWIO.
Namely, suppose that { is a read macro that basically does TYI's.
However, assume that [ and < cause a READ to occur and ] and >
are splicing macros al la (lambda () ()) and that you are scanning something
like:
{[foo] <bar> [abcd] => ...}
The program does a tyi and sees the [, flushes it, and the does (READ file),
getting "foo" (and removing the ] from consideration). Now it does a TYI and
gets > (!!!), then a space, then the < (!!!). Here it does the correct (READ file).
It flushes the > but then the next TYI gets a > again!!!
This sounds suspicious to me.
-rpg-
∨
Date: 4 JAN 1979 1057-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
The IO-LOSSAGE break point when a file is not found, often has
the file-specification before any MERGEFing was done, so it is
hard to figure out just why the file was not found; e.g.
;(OPEN ((* *) FOO BAR) FILE NOT FOUND
maybe we could display both what the user supplied, and what OPEN
really was looking for (in this case, the value of (* *) was
supplied by DEFAULTF, but not always so.)
∨
Date: 3 JAN 1979 0616-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 version
To: (BUG LISP) at MIT-MC
(STATUS GCTIME) seems to give random numbers.
∨
Date: 1 JAN 1979 0016-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
(QUIT 0) returns to DDT with a normal prompt. ≠P re-enters and immediately
valrets :VK to DDT. ≠P again returns 0 at lisp level. RWK asks 'what is this
spurious :VK doing in there?' (i'll second the motion).
-kmp
∨
Date: 30 DEC 1978 1937-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
Could you make MCAR1: be recognized as a device by lisp...? Makes for nice
transportability between ITS's when source lives only on one site. tnx- kmp
∨
Date: 29 Dec 1978 1210-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: EOF error
To: hic at MIT-MC
In certain LISP contexts, if you do a LOAD the standard eof handler seems
to lose. For instance, it will loop at the end of a file, doing a STATO at
$DEV5K+12, jumping to the EOF code (because it's at the end) and then
continuing to test the eof. I haven't been able to figure out why it
loses in the EOF code since it has few comments and I got puzzled. Could
you look at this? Also, don't forget the mode bits problem.
Thanks.
-rpg-
∨
Date: 28 DEC 1978 1920-EST
From: JONL at MIT-MC (Jon L White)
Subject: Device names
To: (BUG LISP) at MIT-MC
The ITS-specific code that tries to figure out if things like PKnn
and ARnn are device names is losing. I think it is a lossage near
IDND1, it should be testing B for zero in addition to checking for
values '0 thru '9.
∨
Date: 28 DEC 1978 2002-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 file-io
To: (BUG LISP) at MIT-MC
MERGEF loses. If you use MACSYMA while **not** connected to
the <macsym> directory you will lose. The following scenario
should describe the bug perfectly (prefix char of line indicates
who is typing at whom):
@CD <MACLISP>
@RUN LISP
%ALLOC ?
*N
%
%*
*(MERGEF '|FOO| '((DSK MACSYM) * FASL))
%((PS MACLISP) FOO FASL /0)
So the problem seems to be in the buggy code of FIL6BT that
attempts to play around with GTJFN.
∨
Date: 23 DEC 1978 1410-EST
From: JONL at MIT-MC (Jon L White)
Subject: XTRSYMS
To: (BUG LISP) at MIT-MC
The SAIL hackers need some more XTRSYMS added in DEFNS:
READ6C TYIMAN CHNTB
probably the first two should just be added, and the third put
under a sail conditional.
∨
Date: 26 DEC 1978 1710-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 interrupts
To: (BUG LISP) at MIT-MC
CC: dang at MIT-XX
MACLISP is advertised to have interrupt meaning for the following
control characters:
↑A, ↑B, ↑C, ↑D, ↑G, ↑R, ↑T, ↑V, ↑W, ↑X, and ↑Z
I believe that ↑Q, ↑S, are macro characters, and ↑K and ↑L are specially
recognized by the read-scanner. Apparently there are two bugs here?
1) on ITS systems, ↑S fails to set ↑Q to (), and
2) on TOPS-20, ↑Q seems to be set up as an interrupt character.
3) on neither system does ↑A set the value of ↑A as it should.
Having interrupt capacity for at least
↑B, ↑G, ↑V, ↑W, ↑X and ↑Z
would be fairly important for TOPS-20 maclisps.
Now there seems also to be a bug in (SSTATUS LINMO T) on the TOPS-20
systems - it affects TLPRIN, but seems not to effect the ruubout scanner.
It woudl be possible to use the standard TOPS-20 JSYS for input, thereby
taking adavantage of all the twenex terminal niceities, if the LINEMODE
worked ok; but when not in linemode, lisp must inspect each character in
order to decide if enough has been buffered up.
∨
Date: 28 Dec 1978 1236-PST
From: Dick Gabriel <RPG at SU-AI>
To: hic at MIT-MC
Could you put in the change at nms6b1-3 in to the source for QIO?
-rpg-
SUBTTL CONVERSION: NAMESTRING => SIXBIT
;;; THIS ONE IS PRETTY HAIRY. IT CONVERTS AN ATOMIC
;;; SYMBOL IN A, REPRESENTING A FILE SPECIFICATION,
;;; INTO "SIXBIT" FORMAT ON FXP. THIS INVOLVES
;;; PARSING A FILE NAME IN STANDARD ASCII STRING FORMAT
;;; AS DEFINED BY THE HOST OPERATING SYSTEM.
;;; FOR D20, THE OPERATING SYSTEM GIVES US SOME HELP.
;;; FOR ITS AND D10, WE ARE ON OUR OWN.
IFN ITS+D10,[
;;; THE GENERAL STRATEGY HERE IS TO CALL PRINTA TO EXPLODEC THE NAMESTRING.
;;; A PARSING COROUTINE TAKES THE SUCCESSIVE CHARACTERS AND INTERPRETS THEM.
;;; EACH COMPONENT IS ASSEMBLED IN SIXBIT FORM, AND WHEN IT IS TERMINATED
;;; BY A BREAK CHARACTER, IT IS PUT INTO ONE OF FOUR SLOTS RESERVED ON FXP.
;;; FOR CMU, WE ALSO ASSEMBLE THE CHARACTERS INTO PNBUF IN ASCII FORM,
;;; SO THAT WE CAN USE THE CMUDEC UUO TO CONVERT A CMU-STYLE PPN.
;;; AR1 HOLDS THE BYTE POINTER FOR ACCUMULATING A NAME.
;;; AR2A HOLDS MANY FLAGS DESCRIBING THE STATE OF THE PARSE:
NMS==:1,,525252 ;FOR BIT-TYPEOUT MODE
NMS.CQ==:1 ;CONTROL-Q SEEN
NMS.CA==:2 ;CONTROL-A SEEN
IFN D10,[
NMS.DV==:10 ;DEVICE SEEN (AND TERMINATING :)
NMS.FN==:20 ;FILE NAME SEEN
NMS.DT==:40 ;. SEEN
NMS.XT==:100 ;EXTENSION SEEN
NMS.LB==:200 ;LEFT BRACKET SEEN
NMS.CM==:400 ;COMMA SEEN
NMS.RB==:1000 ;RIGHT BRACKET SEEN
NMS.ND==:10000 ;NON-OCTAL-DIGIT SEEN
NMS.ST==:20000 ;* SEEN
] ;END OF IFN D10
;;; CONTROL-A IS THE SAIL CONVENTION FOR QUOTING MANY CHARACTERS, BUT WE
;;; ADOPT IT FOR ALL ITS AND D10 SYSTEMS.
NMS6B0: WTA [BAD NAMESTRING!]
NMS6BT: MOVEI TT,(A) ;DON'T ALLOW FIXNUMS AS NAMESTRINGS
LSH TT,-SEGLOG
MOVSI R,FX
TDNE R,ST(TT) ;A FIXNUM?
JRST NMS6B0 ;YES, ILLEGAL AS A NAMESTRING
PUSHN FXP,L.F6BT+1 ;FOUR WORDS FOR FINISHED NAMES, ONE FOR ACCUMULATION
MOVEI AR1,(FXP) ;AR1 HOLDS THE BYTE POINTER FOR ACCUMULATING A NAME
HRLI AR1,440600
SETZ AR2A, ;ALL FLAGS INITIALLY OFF
CMU$ PUSH FXP,PNBP ;FOR CMU, WE NEED THIS TO PARSE THE PPN
CMU$ SETZM PNBUF+LPNBUF-1
HRROI R,NMS6B1 .SEE PR.PRC
PUSH P,A
PUSHJ P,PRINTA ;PRINTA WILL CALL NMS6B1 WITH SUCCESSIVE CHARS IN A
TLNE AR2A,NMS.CA+NMS.CQ
JRST NMS6B0 ;ILLEGAL FOR A QUOTE TO BE HANGING
MOVEI A,40
PUSHJ P,(R) ;FORCE A SPACE THROUGH TO TERMINATE LAST COMPONENT
POP P,A
IFN D10,[
TLNE AR2A,NMS.LB
TLNE AR2A,NMS.RB
CAIA
JRST NMS6B0 ;LOSE IF LEFT BRACKET SEEN BUT NO RIGHT BRACKET
] ;END OF IFN D10
JUMPE AR1,NMS6B0 ;AR1 IS ZEROED IF THE PARSING CORUTINE DETECTS AN ERROR
POP FXP,1+CMU
MOVSI T,(SIXBIT \*\) ;CHANGE ANY ZERO COMPONENTS TO "*"
SKIPN -3(FXP)
MOVEM T,-3(FXP) ;DEVICE NAME
IT$ SKIPN -2(FXP)
IT$ MOVEM T,-2(FXP) ;SNAME
IFN D10,[
MOVE TT,-2(FXP) ;TREAT HALVES OF PPN SEPARATELY
TLNN TT,-1 ;A ZERO HALF BECOMES -1
TLO TT,-1
TRNN TT,-1
TRO TT,-1
MOVEM TT,-2(FXP)
] ;END OF IFN D10
SKIPN -1(FXP)
MOVEM T,-1(FXP) ;FILE NAME 1
SA$ MOVSI T,(SIXBIT \←←←\)
SKIPN (FXP)
MOVEM T,(FXP) ;FILE NAME 2/EXTENSION
POPJ P,
;;; THIS IS THE NAMESTRING PARSING COROUTINE
NMS6B1: JUMPE AR1,CPOPJ ;ERROR HAS BEEN DETECTED, FORGET THIS CHARACTER
CAIN A,↑A
JRST NMS6BQ
CAIN A,↑Q
TLCE AR2A,NMS.CQ ;FOR A CONTROL-Q, SET THE CONTROL-Q BIT
CAIA ;IF IT WAS ALREADY SET, IT'S A QUOTED ↑Q
POPJ P, ;OTHERWISE EXIT
CAIN A,40 ;SPACE?
TLZN AR2A,NMS.CQ ;YES, QUOTED?
SKIPA ;NO TO EITHER TEST
JRST NMS6B9 ;YES TO BOTH, IS QUOTED SPACE
CAILE A,40 ;SKIP OF CONTROL CHARACTER OR SPACE
JRST NMS6B7
;WE HAVE ENCOUNTERED A BREAK CHARACTER - DECIDE WHAT TO DO WITH COMPONENT
NMS6B8: SKIPN D,(AR1)
POPJ P, ;NO CHARACTERS ASSEMBLED YET
IT$ SKIPN -2(AR1) ;IF WE HAVE A FILE NAME 1, THIS MUST BE FN2
10$ TLNN AR2A,NMS.DT ;WE HAVE SEEN A DOT, THIS MUST BE THE EXTENSION
JRST NMS6B5 ;OTHERWISE THIS IS FILE NAME 1
IT$ SKIPE -1(AR1) ;LOSE IF WE ALREADY HAVE A FILE NAME 2
10$ TLNE AR2A,NMS.XT+NMS.LB+NMS.CM+NMS.RB
JRST NMS6BL ;LOSE IF EXTENSION AFTER BRACKETS OR OTHER ONE
IT$ MOVEM D,-1(AR1)
10$ HLLZM D,-1(AR1)
10$ TLO AR2A,NMS.XT ;SET FLAG: WE'VE SEEN THE EXTENSION
;COME HERE TO RESTORE THE BYTE POINTER FOR THE NEXT COMPONENT
NMS6B6: JUMPE AR1,CPOPJ ;IF AN ERROR HAS BEEN DETECTED, EXIT
HRLI AR1,440600
CMU$ MOVE D,PNBP ;FOR CMU, RESET THE PNBUF BYTE POINTER ALSO
CMU$ MOVEM D,1(AR1)
10$ TLZ AR2A,NMS.ND+NMS.ST ;RESET NON-OCTAL-DIGIT AND STAR SEEN FLAGS
SETZM (AR1) ;CLEAR ACCUMULATION WORD
POPJ P,
;COME HERE FOR FILE NAME 1
NMS6B5:
10$ TLNE AR2A,NMS.FN+NMS.DT+NMS.XT+NMS.LB+NMS.CM+NMS.RB
10$ JRST NMS6BL ;LOSE IF TOO LATE FOR A FILE NAME
MOVEM D,-2(AR1) ;SAVE FILE NAME 1
JRST NMS6B6
;HERE WITH A NON-CONTROL NON-SPACE CHARACTER
NMS6B7: TLZN AR2A,NMS.CQ
TLNE AR1,NMS.CA
JRST NMS6B9 ;IF CHARACTER QUOTED (FOR ↑Q, FLAG IS RESET)
CAIN A,":
JRST NMS6DV ;: SIGNALS A DEVICE NAME
IT$ CAIN A,";
IT$ JRST NMS6SN ;; MEANS AN SNAME
IFN D10,[
CAIN A,".
JRST NMS6PD ;PERIOD MEANS TERMINATION OF FILE NAME
CAIN A,133
JRST NMS6LB ;LEFT BRACKET
CAIN A,",
JRST NMS6CM ;COMMA
CAIN A,135
JRST NMS6RB ;RIGHT BRACKET
CAIN A,"*
JRST NMS6ST ;STAR
] ;END OF IFN D10
;HERE TO DUMP A CHARACTER INTO THE ACCUMULATING COMPONENT
NMS6B9:
IFN CMU,[
SKIPE PNBUF+LPNBUF-1
TDZA AR1,AR1 ;ASSUME A COMPONENT THAT FILLS PNBUF IS A LOSER
IDPB A,1(AR1) ;STICK ASCII CHARACTER IN PNBUF
] ;END OF IFN CMU
IFN D10,[
CAIL A,"0
CAILE A,"7
TLO AR2A,NMS.ND ;SET FLAG IF NON-OCTAL-DIGIT
NMS6B4:
] ;END OF IFN D10
CAIGE A,140 ;CONVERT LOWER CASE TO UPPER,
SUBI A,40 ; AND ASCII TO SIXBIT
TLNE AR1,770000
IDPB A,AR1 ;DUMP CHARACTER INTO ACCUMULATING NAME
POPJ P,
NMS6BQ: TLCA AR2A,NMS.CA ;COMPLEMENT CONTROL-A FLAG
NMS6BL: SETZ AR1, ;ZEROING AR1 INDICATES A PARSE ERROR
POPJ P,
NMS6DV: SKIPE D,(AR1) ;ERROR IF : SEEN WITH NO PRECEDING COMPONENT
10$ ;ERROR AFTER OTHER CRUD
10$ TLNE AR2A,NMS.DV+NMS.FN+NMS.DT+NMS.XT+NMS.LB+NMS.CM+NMS.RB
10% SKIPE -4(AR1) ;ERROR IF DEVICE NAME ALREADY SEEN
JRST NMS6BL
MOVEM D,-4(AR1)
10$ TLO AR2A,NMS.DV
JRST NMS6B6 ;RESET BYTE POINTER
IFN ITS,[
NMS6SN: SKIPE D,(AR1) ;ERROR IF ; SEEN WITHOUT PRECEDING COMPONENT
SKIPE -3(AR1) ;ERROR IF WE ALREADY HAVE AN SNAME
JRST NMS6BL
MOVEM D,-3(AR1)
JRST NMS6B6 ;RESET BYTE POINTER
] ;END OF IFN ITS
IFN D10,[
NMS6PD: TLNE AR2A,NMS.DT+NMS.XT+NMS.LB+NMS.CM+NMS.RB
JRST NMS6BL
PUSHJ P,NMS6B8 ;DOT SEEN - SEE IF IT TERMINATED THE FILE NAME
TLO AR2A,NMS.DT ;SET PERIOD (DOT) FLAG
POPJ P,
NMS6LB: TLNE AR2A,NMS.LB+NMS.CM+NMS.RB
JRST NMS6BL ;LEFT BRACKET ERROR IF ALREADY A BRACKET
PUSHJ P,NMS6B8 ;DID WE TERMINATE THE FILE NAME OR EXTENSION?
TLO AR2A,NMS.LB ;SET LEFT BRACKET FLAG
NMS6L1:
SA% HRLI AR1,440300
SA$ HRLI AR1,440600
POPJ P,
NMS6CM: LDB D,[360600,,AR1]
CAIE D,44 ;ERROR IF NO CHARACTERS AFTER LEFT BRACKET
TLNN AR2A,NMS.LB ;ERROR IF NO LEFT BRACKET!
JRST NMS6BL
SA% TLNE AR2A,NMS.ND+NMS.CM+NMS.RB
SA$ TLNE AR2A,NMS.CM+NMS.RB
JRST NMS6BL ;ERROR IF NON-OCTAL-DIG, COMMA, OR RGT BRACKET
PUSHJ P,NMS6PP ;HACK HALF A PPN
HRLM D,-3(AR1)
TLO AR2A,NMS.CM ;SET COMMA FLAG
SETZM (AR1) ;CLEAR COLLECTING WORD
JRST NMS6L1 ;RESET BYTE POINTER
NMS6RB:
LDB D,[360600,,AR1]
CMU% TLNE AR2A,NMS.CM ;MUST HAVE COMMA BEFORE RIGHT BRACKET
CAIN D,44 ;ERROR IF NO CHARS SINCE COMMA/LEFT BRACKET
JRST NMS6BL
TLNE AR2A,NMS.LB ;ERROR IF NO LEFT BRACKET
TLNE AR2A,NMS.RB ;ERROR IF RIGHT BRACKET ALREADY SEEN
JRST NMS6BL
CMU$ TLNE AR2A,NMS.CM ;FOR CMU, NO COMMA MEANS A CMU-STYLE PPN
CMU$ JRST NMS6R1
PUSHJ P,NMS6PP ;FIGURE OUT HALF A PPN
HRRM D,-3(AR1)
NMS6R2: TLO AR2A,NMS.RB ;SET RIGHT BRACKET FLAG
JRST NMS6B6 ;RESET THE WORLD
IFN CMU,[
NMS6R1: MOVEI D,PNBUF
CMUDEC D, ;CONVERT CMU-STYLE PPN TO A WORD
JRST NMS6BL ;LOSE LOSE
MOVEM D,-3(AR1) ;WIN - SAVE IT AWAY
JRST NMS6R2
] ;END OF IFN CMU
NMS6ST: TLOE AR2A,NMS.ST ;SET STAR FLAG, SKIP IF NOT ALREADY SET
TLO AR2A,NMS.ND ;TWO STARS = A NON-DIGIT FOR PPN PURPOSES
JRST NMS6B4
NMS6PP:
SA% TLNE AR2A,NMS.ND
SA% SETZ AR1, ;NON-DIGIT IN PPN IS AN ERROR
HRRZI D,-1
TLNE AR2A,NMS.ST ;STAR => 777777
POPJ P,
LDB TT,[360600,,AR1]
CAIGE TT,22
SETZ AR1, ;MORE THAN SIX DIGITS LOSES
MOVNS TT
MOVE D,(AR1)
LSH D,(TT) ;RIGHT-JUSTIFY THE DIGITS
POPJ P,
] ;END OF IFN D10
] ;END OF IFN ITS+D10
∨
Date: 20 Dec 1978 1550-PST
From: Lisp files <LSP at SU-AI>
Subject: TTY1BE
To: hic at MIT-MC
This mode bits thing is really screwing us, so I'm going to
try changing tty1be+2 from
TLNN R,FBT<LN>
to
TLNN F,FBT<LN>
since I think the right half of F has the correct bits at this point. Or
else I could load as:
MOVE R,F.MODE(T)
-rpg-
∨
JOHAN@MIT-AI 12/19/78 11:37:27
To: (BUG LISP) at MIT-AI
ARRAYCALL with too few args, gets too many args msg.
∨
RWK@MIT-MC 12/17/78 23:58:54
MC:X;SFA LOSAGE is a file of SFA-related LISP bugs. I'm adding my bugs to
this file.
∨
Date: 17 DEC 1978 2153-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
P% doesn't work right when TYO is an SFA. It looks like it's pulling the
channel to write to out of the SFA-array and gets an IOC error. Why doesn't
it just call PRIN1? It would be much more useful to me that way.
∨
Date: 17 DEC 1978 1646-EST
From: rwk at MIT-MC (Robert W. Kerns)
Sent-by: NEAL at MIT-MC
To: (BUG LISP) at MIT-MC
The TTYCONS operation on SFA's is not documented.
∨
Date: 17 DEC 1978 1933-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
(STATUS TTYSIZE) does not work on SFA's.
∨
Date: 17 DEC 1978 1933-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
(STATUS TTYSIZE) does not work on SFA's.
∨
Date: 16 DEC 1978 2017-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
(CNAMEF <sfa> 'FOOBAR) asks <sfa> for it's name and then barfs about
the namelist not being a file array. It should just send the CNAMEF
to the SFA, there's no default handling that can be done.
∨
Date: 16 DEC 1978 2032-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
Also, CHARPOS is not documented in .INFO.;LISP SFA
∨
Date: 16 DEC 1978 2212-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: Magic File Array
To: (BUG LISP) at MIT-MC
CC: GSB at MIT-MC
Alright, where do you hide it.
MSGFILES is '(T), TYO is CONSOLE-OUTPUT, I do
(TYO 5 FOO)
and it does
;<mumble> LOSING OUTPUT FILE
OK, so where is the output file that it writes the <mumble> to?
It's certainly not going through TYO, unless it's on a character-by-character
basis!
∨
Date: 17 DEC 1978 0436-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
Another operation which transmits gibberish as data is LINEL
(LINEL CONSOLE-OUTPUT)
=> argument was #SFA-|CONSOLE-OUTOUT|-70706
It should be nil.
Also, LINEL is not documented in .INFO.;LISP SFA
∨
Date: 17 DEC 1978 0454-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
TYIPEEK with args is not documented, and doesn't seem to work right.
In particular, the argument always seems to be this frob of type RANDOM.
∨
Date: 17 DEC 1978 0254-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: GSB at MIT-MC
(SETQ TYO CONSOLE-OUTPUT)
(STATUS TERPRI)
; #SFA-|CONSOLE-OUTPUT|-@#$%@↑$ NOT TTY OUTPUT FILE
(SSTATUS TERPRI)
; #SFA-|CONSOLE-OUTPUT|-@#$%@↑$ NOT TTY OUTPUT FILE
Bletch. Moby bletch. What does it need to do with a TTY output file
to perform this function? Why isn't it something that an SFA can handle?
This makes SPRINTER useless in this environment.
∨
GSB@MIT-ML 12/17/78 03:06:54 Re: (Status Terpri)
To: RWK at MIT-MC, (BUG LISP) at MIT-MC
CC: GSB at MIT-ML
Should be something which can be set on a per-file basis. It's meaning
is that lisp will not auto-terpri on hitting the end of the line. As far
as i can tell, there is no reason for it to be restricted to tty files.
It is a loss to set the linel to 0, because that will severely confuse
pretty-printers; binding TERPRI isn't all that hot, especially when
debugging, because then one doesn't get the hairy prin1 auto-terpri
stuff.
How about AUTOTERPRI (lsubr, 1 or 2 args) and flush (status terpri)?
This could be trivially extended to sfa's, too.
Sprinter probably should be binding TERPRI anyway, i suppose that
it means it for everything, not just the tty.
∨
Date: 16 DEC 1978 1857-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
(DEFUN FOO-SFA (SELF OP DATA)
(CASEQ OP (WHICH-OPERATIONS '(CHARPOS TYO))
(T (FORMAT T '|}&Operation = }S, Data = }S}&| OP DATA)
0))) ;need to return a fixnum
(CHARPOS FOO)
Operation = CHARPOS, DATA = #SFA-|FOO|-234153
Barf. It should probably pass in NIL as the third argument if there's no
second argument to the CHARPOS.
Also, if you don't return a fixnum, it complains about "Wrong type argument".
This is clearly the wrong error message from the user's point of view.
Probably something like "Illegal return value" would make more sense.
∨
Date: 16 DEC 1978 1940-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC
The RENAMEF operation on SFA's doesn't seem to work properly. I've noticed
several things which are not as I'd expect:
1) It's not documented.
2) (RENAMEF FOO-SFA 'MUMBLE) does a NAME operation, expecting this to
return a namestring.
3) The NAME operation is not documented.
4) The NAME operation is invoked without checking the WHICH-OPERATIONS mask.
5) There's no bit in the WHICH-OPERATIONS mask for the NAME operation.
6) It seems that it insists on trying to do a NAME operation even if there
is a RENAMEF operation (and the RENAMEF bit is on in the mask)
7) It seems that no matter what, I can't get it to ever call the SFA with the
RENAMEF operation. It insists on trying to do a RENAME, the intent is to
pass a RENMWO onto the file the SFA is outputing to.
∨
Date: 14 Dec 1978 2246-PST
From: Beverly Kedzierski <BIK at SU-AI>
Subject: No init file
To: bug-lisp at MIT-MC
We in "TOPS-10"-land need to be able to say "no ini (init)
file please".
-rpg-
∨
Date: 13 DEC 1978 2147-EST
From: JONL at MIT-MC (Jon L White)
Subject: Use of COMMON
To: (BUG LISP) at MIT-MC
there is a list which the +INTERNAL-AUTOLOAD function uses in a
call to MERGEF - "(DSK COMMON)". This should probably be "(DSK LISP)"
for ITS systems, and "(DSK MACLISP)" for TOPS-20 systems.
Also, the default second file name for TOPS-20 systems should be "LSP"
instead of "MACLISP".
∨
Date: 13 Dec 1978 1702-PST
From: Lisp files <LSP at SU-AI>
Subject: Linmode
To: HIC at MIT-MC
I've got a question about linmode. Suppose one is in it. Supposedly
during the ttyb1 etc rigamarole the second thing down on the fxp should be
the mode bits (see comment at ttyb1:). However, the mode bits are:
400000, not 441000, which means linmode, full character set, plus 400000.
Now this doesn't seem to screw us normally (for some reason), but if you
manage to get a TTY open in ASCII mode, as you can do with a non-smart
telnet to SAIL, or by JFCLing out the GETLIN at OPNTI1+11, then the mode
screwup seems to get us at TTYB1E+2, where you check to see if you are
in linmode based on those saved bits. Now, one MIGHT get around this with
making the TLNN R be a TLNN F, since F contains the mode bits ok (I think)
at this point. However, I'm afraid that there is something else afoot.
In ASCII mode, <cr>'s are ignored, so that sequences of atoms separated
by them get concatenated. Could you think about this and let me know how to
best patch it?
-rpg-
∨
Date: 13 Dec 1978 1414-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: EFILEFLAG
To: HIC at MIT-MC
How about setqing the global "EFILEFLAG" to T or NIL depending
on whether the file opened was an e file.
-rpg-
∨
Date: 12 Dec 1978 1647-PST
From: Lisp files <LSP at SU-AI>
To: HIC at MIT-MC
Could you put this pushj p,saext into the sorce file QIO?
-rpg-
SUBTTL RENAMEF FUNCTION, CNAMEF FUNCTION
;;; (RENAMEF X Y) RENAMES (MERGEF X (NAMELIST NIL)) TO BE
;;; (MERGEF Y (MERGEF X (NAMELIST NIL))).
;;; IF X IS AN OUTPUT FILE ARRAY, IT IS RENAMED AND CLOSED.
$RENAMEF:
PUSHJ P,2MERGE ;2MERGE LEAVES ARG 1 IN AR1
JSP TT,XFILEP ;SKIP IF FILE ARRAY
JRST RENAM2
MOVE TT,TTSAR(AR1)
TLNE TT,TTS.CL
JRST RENAM2
HLLOS NOQUIT
MOVEI A,(AR1)
IFN ITS,[
.CALL RENAM7 ;MUST RENAME WHILE OPEN
IOJRST 0,RENAM6
] ;END OF IFN ITS
PUSHJ P,JCLOSE ;RETURNS CHANNEL IN T, TTSAR IN TT
IFN D10,[
MOVE F,F.CHAN(TT)
MOVE T,-1(FXP)
HLLZ TT,(FXP)
SA% PUSHJ P, SAEXT
SETZ D,
MOVE R,-2(FXP)
LSH F,27
IOR F,[RENAME 0,T]
XCT F
IOJRST 0,RENAM6
SA$ XOR F,[<CLOSE 0,0>#<RENAME 0,T>]
SA$ XCT F
SA$ XOR F,[<RELEASE 0,0>#<CLOSE 0,0>]
SA% XOR F,[<RELEASE 0,0>#<RENAME 0,T>]
XCT F
] ;END OF IFN D10
IFN D20,[
PUSH P,F.JFN(TT)
RENAM0: PUSH P,[-1]
PUSHJ P,X6BTNS
POPI P,1
POP P,T
MOVSI 1,(GJ%FOU+GJ%NEW+GJ%ACC+GJ%SHT)
MOVE 2,PNBP
GTJFN
IOJRST 0,RENAM5
MOVE 2,1
MOVE 1,T
HRLI 1,(CO%NRJ)
CLOSF
IOJRST 0,RENAM4
TLZ 1,-1
RNAMF
IOJRST 0,RENAM4
MOVE 1,2
RLJFN ;? SHOULD GC DO THE RELEASE?
HALT
] ;END OF IFN D20
IFN ITS+D10,[
MOVE F,-1(FXP) ;UPDATE THE FILE NAMES
MOVEM F,F.FN1(TT)
10$ MOVEM F,F.RFN1(TT)
IT$ MOVE F,(FXP)
10$ HLLZ F,(FXP)
MOVEM F,F.FN2(TT)
10$ MOVEM F,F.RFN2(TT)
10$ MOVE F,-2(FXP)
10$ MOVEM F,F.PPN(TT)
10$ MOVEM F,F.RPPN(TT)
IT$ .CALL RFNAME ;READ BACK THE TRUENAMES
IT$ .LOSE 1400 ;END OF IFN ITS+D10
IT$ .CALL CLOSE9
IT$ .LOSE 1400
] ;END OF IFN ITS+D10
IFN D20,[
MOVEI T,F.DEV(TT)
HRLI T,-L.F6BT+1(FXP)
BLT T,F.DEV+L.F6BT-1(TT)
] ;END OF IFN D20
PUSHJ P,CZECHI
POPI FXP,L.F6BT
20$ JUMPE AR1,RENAM3
MOVEI A,(AR1)
RENAM1: POPI FXP,L.F6BT
POPJ P,
RENAM2:
IFN ITS,[
.CALL RENAM8 ;ORDINARY RENAME
IOJRST 0,RENAM9
] ;END OF IFN ITS
IFN D10,[
MOVEI T,.IODMP ;TO RENAME A FILE, WE OPEN A DUMP MODE CHANNEL
MOVE TT,-7(FXP) ;GET DEVICE NAME
SETZ D,
OPEN TMPC,T ;OPEN CHANNEL
JRST RENAM4
MOVE T,-5(FXP) ;FILE NAME
HLLZ TT,-4(FXP) ;EXTENSION
SA$ PUSHJ P,SAEXT
SETZ D,
MOVE R,-6(FXP) ;PPN
LOOKUP TMPC,T ;LOOK UP FILE
IOJRST 0,RENAM5
MOVE T,-1(FXP) ;NEW FILE NAME
HLLZ TT,(FXP) ;NEW EXTENSION
SETZ D,
MOVE R,-2(FXP) ;NEW PPN
RENAME TMPC,T ;RENAME FILE
IOJRST 0,RENAM5
RELEASE TMPC,
] ;END OF IFN D10
IFN D20,[
MOVEI T,L.F6BT
PUSH FXP,-2*L.F6BT+1(FXP) ;COPY OLD FILE NAMES TO TOP OF FXP
SOJG T,.-1
PUSH P,[-1] ;FLAG SAYING LONG NAMESTRING
PUSHJ P,6BTNS ;STRING OUT INTO PNBUF
POPI P,1
MOVE 2,PNBP
GTJFN ;GET A JFN FOR OLD FILE NAMES
IOJRST 0,RENAM6
PUSH P,1
SETZ AR1, ;GO RENAME THE FILE, RETURNING TO RENAM3
JRST RENAM0
RENAM3:
] ;END OF IFN D20
PUSHJ P,6BTNML ;RETURN VALUE IS NAMELIST
JRST RENAM1
IFN ITS,[
RENAM7: SETZ
SIXBIT \RENMWO\ ;RENAME WHILE OPEN
,,F.CHAN(TT) ;CHANNEL #
,,-1(FXP) ;NEW FILE NAME 1
400000,,(FXP) ;NEW FILE NAME 2
RENAM8: SETZ
SIXBIT \RENAME\ ;RENAME
,,-7(FXP) ;DEVICE NAME
,,-5(FXP) ;OLD FILE NAME 1
,,-4(FXP) ;OLD FILE NAME 2
,,-6(FXP) ;SNAME
,,-1(FXP) ;NEW FILE NAME 1
400000,,(FXP) ;NEW FILE NAME 2
] ;END OF IFN ITS
IFN D20,[
RENAM4: RLJFN ? WARN [ARE AC'S OKAY HERE?]
HALT
RENAM5: MOVE 1,T
RLJFN
HALT
] ;END OF IFN D20
IFN D10,[
RENAM4: SKIPA C,[NSDERR]
RENAM5: RELEASE TMPC,
] ;END OF IFN D10
RENAM6: PUSHJ P,CZECHI
RENAM9: PUSHJ P,6BTNML ;ERROR MESSAGE IS IN C
PUSHJ P,NCONS
PUSH P,A
PUSHJ P,6BTNML
POP P,B
PUSHJ P,CONS
MOVEI B,Q$RENAMEF
XCIOL: PUSHJ P,XCONS ;XCONS, THEN IOL
%IOL (C)
10$ NSDERR: SIXBIT \NO SUCH DEVICE!\
IFN ITS,[
RFNAME: SETZ
SIXBIT \RFNAME\ ;READ FILE NAMES
,,F.CHAN(TT) ;CHANNEL #
2000,,F.RDEV(TT) ;DEVICE NAME
2000,,F.RFN1(TT) ;FILE NAME 1
2000,,F.RFN2(TT) ;FILE NAME 2
402000,,F.RSNM(TT) ;SNAME
] ;END OF IFN ITS
CNAMEF: PUSHJ P,2MERGE ;LEAVES FIRST ARG IN AR1
JSP TT,XFILEP
JRST CNAME1
MOVE TT,TTSAR(AR1)
TLNN TT,TTS.CL ;FILE-ARRAY MUST BE CLOSED
JRST CNAME2
ADDI TT,L.F6BT
MOVEI F,L.F6BT ;COUNTER TO TRANSFER WORDS
CNAME3: MOVE T,(FXP)
MOVEM T,F.DEV-1(TT)
20% POP FXP,F.RDEV-1(TT)
SUBI TT,1
SOJG F,CNAME3
POPI FXP,L.F6BT
20$ POPI FXP,L.F6BT
MOVEI A,(AR1)
POPJ P,
CNAME2: SKIPA C,[CNAER2]
CNAME1: MOVEI C,CNAER1
CNAMER: PUSHJ P,6BTNML ;ERROR MESSAGE IS IN C
PUSHJ P,NCONS
PUSH P,A
PUSHJ P,6BTNML
POP P,B
PUSHJ P,CONS
MOVEI B,QCNAMEF
PUSHJ P,XCONS ;XCONS, THEN IOL
%IOL (C)
CNAER1: SIXBIT/NOT FILE ARRAY!/
CNAER2: SIXBIT/FILE ARRAY NOT CLOSED!/
∨
Date: 11 Dec 1978 1537-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: slight change
To: hic at MIT-MC
Could you edit in the change:
LDSCRU+1 exit
to be
LDSCRU+1 jrst ldrihs+3 (a core2 t,)
The purpose is so that is you are trying to depurify the hiseg, it can
win even though there are no job slots.
-rpg-
ps you might want to sleep a bit before the jrst.
∨
Date: 12 Dec 1978 1324-PST
From: Lisp files <LSP at SU-AI>
To: hic at MIT-MC
here's the code to make the setq t nil etc work right. The sos ipspc(f)
should be out for SAIL, we get the right address.
;;; IFN QIO
;;; MEMORY AND OPCODE ERRORS: PARITY, PURE, MPV, ILOP.
;;; ASSUME NO MORE THAN ONE HAPPENS AT A TIME.
MEMERR:
IT$ .SUSET [.RJPC,,JPCSAV]
MOVE F,INTPDL
MOVE D,FXP
SKIPE GCFXP
MOVE FXP,GCFXP
PUSH FXP,D
SA% 10$ SOS IPSPC(F) ;MAKE PC POINT TO OFFENDING INSTRUCTION
MOVN R,IPSWD1(F) ;THIS SEQUENCE KILLS THE LOW-ORDER
ANDCA R,IPSWD1(F) ; BIT FROM THE INTERRUPT WORD
; FOR D10, WILL CONTAIN APR FLAGS OF MERIT
SKIPE R ;LOSE IF MORE THAN ONE BIT WAS SET
IT$ .LOSE
IFN D10+D20, HALT
MOVE R,IPSWD1(F)
HRRZ D,IPSPC(F)
IT$ CAIN D,THIRTY+5 ;DDT DOES ≠X IN LOCATION 34
IT$ JRST $XLOSE
TLNE R,(%PI<PAR>) ;WAS IT A PARITY ERROR?
JRST PARERR
TLNE R,(%PI<WRO>) ;WRITE INTO READ-ONLY?
JRST PURPGI
TRNE R,%PI<ILO> ;ILLEGAL OPERATION?
JRST ILOPER
TRNN R,%PI<MPV> ;MEMORY PROTECT VIOLATION?
.VALUE ;NO??? WHAT HAPPENED???
CAIE D,UBD1 ;LET SPECPDL RESTORATION HAPPEN
JRST MPVERR ; EVEN IF ONE SLOT GOT CLOBBERED
AOS IPSPC(F) ;BUMP PC PAST OFFENDING INSTRUCTION
JRST INTXIT
MPVERR: SKIPA D,[UIMMPV]
PURERR: MOVEI D,UIMWRO
JRST MEMER5
ILOPER: SKIPA D,[UIMILO]
PARERR: MOVEI D,UIMPAR
MEMER5: HRRZ R,INTPDL ;MACHINE ERROR! WHAT TO DO?
CAIN R,INTPDL+LIPSAV ;IF THE ERROR HAPPENED WITHIN AN INTERRUPT SERVER,
SKIPN VMERR ; OR IF USER SUPPLIED NO ERROR FUNCTION,
JRST MEMER7 ; CRAP OUT BACK TO DDT
MOVEI D,100000(D)
HRL D,IPSPC(F)
PUSHJ FXP,$IWAIT
JRST XUINT ;CALL USER INTERRUPT HANDLER
; JRST INTXIT ;MAY RE-DO LOSING INSTR, BUT SO WHAT?
; THAT'S A FEATURE, NOT A BUG.
ANDI D,777
MEMER7:
IFN ITS,[
HRRZ R,MEMER8(D)
JRST INTLOS
MEMER8:
OFFSET -.
UIMPAR:: 1+.LZ %PIPAR
UIMILO:: 1+.LZ %PIILO
UIMWRO:: 1+.LZ %PIWRO
UIMMPV:: 1+.LZ %PIMPV
OFFSET 0
$XLOST: .VALUE [ASCIZ \:≠ YOUR ≠↔≠⊗X LOST ≠↔PROCEED⊗ \]
JRST THIRTY+5 ;LET THE ≠X RETURN CORRECTLY
$XLOSE: MOVEI R,$XLOST ;CAUSE INTERRUPT DURING AN ≠X
MOVEM R,IPSPC(F) ; TO GO TO $XLOST (CROCK)
JRST INTXIT
] ;END IFN ITS
IFN D10,[
OUTSTR @MEMER8(D) ;GIVE ERROR IF USER DOESN'T WANT IT
EXIT 1,
JRST .-2
] ;END IFN D10
IFN D20,[
HRRO 1,MEMER8(D) ;GIVE ERROR
PSOUT
HALTF ;THEN STOP EXECUTION NICELY
] ;END IFN D20
IFN D10+D20,[
MEMER8:
OFFSET -.
UIMPAR::[ASCIZ \?Parity error in job
\]
UIMILO::[ASCIZ \?Illegal op executed
\]
UIMWRO::[ASCIZ \?Write into read-only memory
\]
UIMMPV::[ASCIZ \?Memory protection violation
\]
OFFSET 0
] ;END IFN D10+D20
∨
Date: 11 DEC 1978 1123-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 renamef
To: (BUG LISP) at MIT-MC
1) RENAMEF apparently fails to do the corresponding CNAMEF as is
done on the ITS version
2) RENAMEF fails to accept namelist, but barfs about illegal
source/destination designator
3) If one does a RENAMEF while the file is open, then subsequent calls
to TRUENAME on the open file-object re4sult is illegal op code execution.
∨
JPG@MIT-MC 12/10/78 04:18:18
To: HIC at MIT-MC
CC: JPG at MIT-MC
For XX-MACSYMA, (SHOWTIME:ALL,RATSIMP((X+Y)↑200))$ gives a large negative
GC-time, i.e. Totaltime=4105 msecs., GCtime=-16703878 msecs.
This works fine on MC.
∨ HIC@MIT-MC 12/10/78 03:40:44
MEREGEF on Tops-20 loses.
∨
Date: 9 Dec 1978 2241-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: Awright you losers!
To: bug-lisp at MIT-MC
;Edit
← (CR (DEFUN FOO (A) (WHILE T DO (SETQ A (CONS A A))))))))
← αβO
FOO
← (FOO NIL)
;GC DUE TO LIST SPACE
; 70.[0%] LIST, 708.[69%] FIXNUM, 511.[99%] FLONUM,
; 507.[99%] BIGNUM, 744.[36%] SYMBOL, 470.[91%] ARRAY WORDS FREE
;ADDING 5 NEW LIST SEGMENTS
; BUT DIDN'T SUCCEED -- LIST SPACE NOW 10752 WORDS
...INCREASING LIST GCMAX TO 11384. WORDS...
;GC DUE TO LIST SPACE
; 37.[0%] LIST, 708.[69%] FIXNUM, 511.[99%] FLONUM,
; 507.[99%] BIGNUM, 744.[36%] SYMBOL, 470.[91%] ARRAY WORDS FREE
;ADDING 6 NEW LIST SEGMENTS
; BUT DIDN'T SUCCEED -- LIST SPACE NOW 11776 WORDS
...INCREASING LIST GCMAX TO 12400. WORDS...
;GC DUE TO LIST SPACE
;PDL OVERFLOW WHILE IN GC!
;MAJOR RESTART UNDERTAKEN
;GC DUE TO STARTUP
; 5628.[47%] LIST, 708.[69%] FIXNUM, 511.[99%] FLONUM,
; 507.[99%] BIGNUM, 744.[36%] SYMBOL, 470.[91%] ARRAY WORDS FREE
← ↑C
↑C
.R PPSAV
-rpg-
∨
Date: 6 DEC 1978 1527-EST
From: JONL at MIT-MC (Jon L White)
Subject: NAMELIST components on DEC10
To: (BUG LISP) at MIT-MC
It would help a lot if ((* *) ...) would mean the same to
namelist processors as ((* (* *)) ...)
∨
RWG@MIT-MC 12/06/78 00:19:48
i hate to bring this up so near the holidays, but:
any progress on rem's disapearing listpace mystery?
∨
Date: 5 DEC 1978 0954-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
Quite regularly, I can make LISP bomb out to ddt with
ILOPR; INTPDL+10>> . . .
It seems to be a timing bug of some sort, since it occurs aafter typing
↑B at a running expr complr, but not all the time.
∨
Date: 5 DEC 1978 1128-EST
From: JONL at MIT-MC (Jon L White)
Subject: (TYIPEEK <frob> <file> -3)
To: (BUG LISP) at MIT-MC
will return -1 regardless of the setting of -3.
Probably no one is shafted by this, but it is inconsistent with
the documentation.
∨
Date: 2 DEC 1978 0037-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC
CC: RWK at MIT-MC, (FILE [HIC;LISP THINGS]) at MIT-MC
I guess I'm pretty well convinced, so that on my next LISP hacking
session I'll fix NCONC, APPEND, etc to listen to *RSET and do the "right"
thing if the list isn't a real "list". I don't guarantee when this'll
happen, but.....
∨
Date: 30 NOV 1978 2316-EST
From: JONL at MIT-MC (Jon L White)
Subject: Generation numbers on TWENEX
To: (BUG LISP) at MIT-MC
1) ">" should be acceptable as a generation number, meaning roughly
the same thing as when used a a second file name for ITS
2) default generation number for UWRITE and OPEN (with open option OUT)
seems random - possibly defaulting the same as device or directory
to the last one mentioned specifically in a UREAD or input OPEN
3) UFILE returns a list which consists of the temporary name instead of
the final renamed name
4) (UREAD FOO BAR /8) should recognize the /8 as a generation number
rather than a device name
∨
RWK@MIT-MC (Sent by JIS@MIT-MC) 11/25/78 23:48:26 Re: previous message, LENGTHF
To: HIC at MIT-MC, JPG at MIT-MC
Hmm. LENGTHF seems only to work on INPUT files. That seems to me to be
a loss.
∨
Date: 25 NOV 1978 1532-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
TYIPEEK seems to ignore its third arg. Doing
(OPEN <file> '(IN ASCII))
(FILEPOS <file-obj> T)
(TYIPEEK NIL <file-obj> -2.)
returns -1 for the last form - same as if I just typed
(TYIPEEK NIL <file-obj>)
Shudn't this be consistent with TYI? -1 seems like an ok default if
no 3rd arg is given, but I think making the 3rd arg be the return value
at an EOF is only fair.
∨
Date: 24 NOV 1978 2038-EST
From: RWK,KMP at MIT-MC
Sent-by: KMP at MIT-MC
To: (BUG LISP) at MIT-MC
For the sake of compatibility with existing programs, and consistancy,
+TYO should *NOT* barf "not ascii output file" when you give it an SFA, but
should simply do an implicit (SFA-CALL <file> '+TYO <arg>).
∨
Date: 24 NOV 1978 2044-EST
From: RWK, KMP at MIT-MC
Sent-by: KMP at MIT-MC
To: (BUG LISP) at MIT-MC
(STATUS FILEMODE) seems never to invoke the SFA to ask it to describe
itself. It always returns the ((SFA) {results of a WHICH-OPERATIONS call})
list, in the test we tried.
∨
Date: 24 NOV 1978 2333-EST
From: JONL at MIT-MC (Jon L White)
Subject: TWENEX version
To: (BUG LISP) at MIT-MC
(UFILE FOO BAR) returns ((dev usr) MACLISP OUTPUT ||)
shouldn't it return ((dev usr) FOO BAR /n) ?
∨
rich,johan@MIT-AI (Sent by JOHAN@MIT-AI) 11/24/78 09:49:05 Re: READ
To: (BUG LISP) at MIT-AI
In the current lisp (READ 'FOO) and (READ 'FOO 'FOO) both read
from the TTY instead of giving a losing filespec error. Isn't
this a bug?
∨
Date: 22 NOV 1978 2038-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 alloc prompt
To: (BUG LISP) at MIT-MC
Doug Blewett suggests using RDTTY instead of PBIN in alloc to
gobble down the "Y" or "N", and that should fix the superfluous
<cr> problem.
∨
Date: 22 NOV 1978 0341-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
(SSTATUS LINMO T)
has only part of the desired effect - it affects the toplevel
printer, but seems not to affect the rubout-processor.
∨
Date: 22 NOV 1978 0714-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
In TOPS-20 version, <control>-Q doesn't seem to do anyting.
∨
Date: 22 NOV 1978 0726-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
TOPS-20 version gives (STATUS UDIR) = (STATUS HOMEDIR), but if one is
"connected" to a directory other than the login name, then these two should
be different?
∨
alan,dlw@MIT-AI (Sent by ALAN@MIT-AI) 11/22/78 14:01:33 Re: lexpr implode
To: hic at MIT-MC
while you are at it you could make implode explode any of its arguments that
are symbols. So (implode 'foo '(b a r)) => foobar. Only problem is, what about
nil?
∨
ALAN@MIT-AI 11/22/78 00:37:51 Re: defun& and other winnitude.
To: hic at MIT-MC
1) I just glanced over defun& and I think it now conforms to
what jonl had in mind. (I know you don't care.)
2) Here is an idea for a usefull maclisp function:
How many times have you seen people doing (implode (append foo bar baz))?
Why not a function (you-name-it foo bar baz) that would do this for
you without forcing you to copy all that list structure? On second thought
why not just make implode be a lexpr?
∨
Date: 21 Nov 1978 1938-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: You won't believe this
To: HIC at SU-AI
BH and I found yet another bug in the system for moving
the output buffers. The code for gcbib[l;newgc >] contains the
changes. Here's a tip, if you didn't add anything yourself to GCBIB,
roll back to before any changes were made on this matter since the
protocol has reverted to the original. What happens is that users
keep finding cases that screw the system. I hope this will be it.
I think we'll be able to fly you out in December.
-rpg-
∨
Date: 21 Nov 1978 1440-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: length of character changes
To: HIC at SU-AI
HIC, can you make this change to PRINT? Also, if you can find any other
places where ascii 0-40 are 2 wide? Thanks.
-rpg-
TYOF3: CAIN TT,33 ;ALTMODES ARE ALWAYS 1 WIDE
JRST TYOF0D
MOVE D,F.MODE(T) ;RANDOM CONTROL CHAR
IFE SAIL,[
IT$ CAIE TT,177 ;RUBOUT PRINTS TWO POSITIONS EVEN IN SAIL MODE
TLNN D,FBT<SA> ;SKIP IF SAIL MODE FILE
AOS AT.CHS(T) ;OTHERWISE CONTROL CHARS ARE 2 WIDE
] ;end of IFE SAIL
JRST TYOF0D
TYOFBS: SKIPLE AT.CHS(T) ;BACKSPACE - UNLESS AGAINST LEFT MARGIN,
SOS AT.CHS(T) ; DECREMENT CHARPOS
SETZM ATO.LC(T) ;CLEAR / FLAG
JRST TYOF4
TYOFTB: MOVEI D,7 ;TAB FOUND - JUMP TO NEXT
IORM D,AT.CHS(T) ;MULTIPLE-OF-8 CHARPOS
JRST TYOF0D
TYOFLF: AOS D,AT.LNN(T) ;INCREMENT LINENUM
SKIPLE FO.PGL(T) ;ZERO PAGEL => INFINITY
CAMGE D,FO.PGL(T) ;SKIP IF OVER PAGE LENGTH
JRST TYOF4
TYOFFF: SETZM AT.LNN(T) ;ZERO LINE NUMBER
AOS AT.PGN(T) ;INCREMENT PAGE NUMBER
TLNN T,TTS.TY ;IF TTY THEN DON'T GIVE END PAGE INT ON ↑L
SKIPN FO.EOP(T) ;IF IT HAS AN ENDPAGEFN, THEN
JRST TYOF4 ; WANT TO GIVE USER INTERRUPT
PUSHJ P,TYOF4
MOVEI D,200000+2*FO.EOP+1
HRLI D,(AR1)
JRST UINT
TYOF7: SKIPLE FO.LNL(T) ;INFINITE LINEL
TLNE T,TTS<IM> ; OR IMAGE MODE TTY
POPJ P, ; => IGNORE FORMAT DATA
SKIPN V%TERPRI
SKIPN AT.CHS(T) ;CAN'T DO ANY BETTER THAN TO BE
POPJ P, ; AT THE BEGINNING OF A LINE
MOVEI D,(TT)
ADD D,AT.CHS(T)
CAMG D,FO.LNL(T)
POPJ P,
SETZM AT.CHS(T)
PUSH FXP,TT
MOVEI TT,↑M ;IF TOO LONG, DO AN AUTO-TERPRI
PUSHJ P,TYOFCR
POP FXP,TT
POPJ P,
TYOFCR: SETZM AT.CHS(T) ;CR - SET CHARPOS TO ZERO
PUSHJ P,TYOF4
SETOM ATO.LC(T) ;SET LF FLAG (MUSTN'T DO UNTIL AFTER IOT
POPJ P, ; OF CR BECAUSE A **MORE** MIGHT OCCUR)
∨
Date: 20 NOV 1978 1535-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
(GETMIDASOP 'LERE) ==> 0
should be ().
∨
SUN@MIT-MC 11/17/78 10:08:26
ML is down so I don't know if you have said anything to me.
Here are the patches. You can be straight forward
and patch the source and then process it or obscure and pathc
the teco.tec. In the A macro to fix ↑K, after the
q0-11 "e -dq5k
stick in a oclear$
To fix the ↑O and <CR> you do to patches:
After get rid of the rest of that line by for example
(I just got screwed by net, after word after above , read
∨
SUN@MIT-MC 11/17/78 10:14:31
Sorry for this nonsense, trying to send an excl just
chopped this message in half. ...so for the second patch
after the label , retcom, get rid of the rest of the line.
Then a few lines down after the lable , retcom2, add
a oclear$.
Therefore all you need to have done is added to oclears and commeout the rest of the retcom line. I have written a version
here that incorporates these changes. oh well see you later.
∨
Date: 17 NOV 1978 1400-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC
LISP doesn't seem to recognize EOF-in-READ errors while inside backquote.
∨
GSB@MIT-ML 11/19/78 08:06:42
To: (BUG LISP) at MIT-ML
(GETDDTSYM IOJRST) CAN'T GET DDT SYMBOL - FASLOAD
Can't this go in GETMIDASOP? CALL and friends do...
∨
GSB@MIT-ML 11/16/78 03:01:59 Re: %TOSA1, %TOSAI, %TSSAI
To: JONL at MIT-MC
CC: GSB at MIT-ML, HIC at MIT-MC
Well, it may take one more bit in f.mode or somewhere similar (which
there isn't.) Clearly the bit which is used for 'sail' in f.mode now
should reflect the %TSSAI bit of the ttysts word, as all of its uses
are for telling whether outputting a char will output a sail graphic.
But there should be a way for telling whether or not the terminal is
capable of outputting sail graphics; the former should appear in
the car of the filemode list (maybe even be an open option, but if
it gets reset by whatever mungs the bit, then that doesn't really matter)
and the latter in the cdr of the filemode list, as it is a capability,
like the ability to cursorpos or rubout.
I guess part of the problem for handling this right is that (status tty)
is a horrid crock; that is, even though the references to an 'input tty'
and an 'output tty' end up the same on ITS (presumably elsewhere?),
there are some things in there which logically refer to input and some
to output channels; and you want to, upon changing some of these, modify
the appropriate bits in f.mode. (Scroll mode has this problem, too.)
I guess a lot of this could be done by a midas package; if the problem
is deemed too hairy for lisp, i could put one together.
(eg, (SCROLL-MODE tty-output-file &OPTIONAL flag-to-set-it-to);
(SAIL-MODE tty-output-file &OPTIONAL flag-to-set-it-to);
(INPUT-ECHO tty-input-file &OPTIONAL flag-to-set-it-to),
;; that would toggle echoing for effectively everything.
)
∨
GSB@MIT-ML 11/13/78 06:02:45
To: SJOBRG at MIT-ML
CC: (BUG LISP) at MIT-ML, GSB at MIT-ML
Output of sail characters is controled by a bit in one of the words
which can be hacked with (status tty).
What you want to do is
((lambda (s) (sstatus tty (car s) (cadr s) (boole 7 (caddr s) 4←27.) t)
(status tty t))
If you had done a :tctype sail before starting up the lisp, then this
would not be necessary. (The rest of this message is primarily directed
to bug-lisp.)
There appears to be a problem in lisp which may make doing this cause
incorrect rubout processing and/or charpos setting: lisp sets the SAIL
option (which is a tty capability bit, rather than an option) from
%TOSA1; this is the wrong thing to do! As a 'capability' it should come
from %TOSAI; as an option (which lisp does not support), it should come
from the ttysts word, %TSSAI. Initializing it only from %TOSA1 makes it
impossible to dynamically change whether or not one wants to use the
sail character set and have lisp behave correctly. It looks to me as
if SAIL should appear if the CDR of a status-filemode list iff the tty
supports sail characters (from %TOSAI), and in the car (as an
open-option) from %TSSAI; only the latter should be used by the rubout
function, tyo, etc.
∨
GSB@MIT-ML 11/13/78 23:37:11
To: (BUG LISP) at MIT-ML
purcopying an array appears to set the i-am-a-flonum-array-bit (100 octal)
in the asar of the array. It neither references the bit nor the asar
symbolically. It is i presume supposed to set the tts.cn bit in the
ttsar.
∨
HIC@MIT-AI 11/11/78 11:41:35
To: HIC at MIT-AI
Jeff Deutsch
WPI
Box 2243
Worcester, Mass 01609
Wants new MacLISP manual
∨
HIC@MIT-MC (Sent by HIC0@MIT-MC) 11/11/78 14:27:02
look into macsyma bug where by not being connected to <MACSYM>
causing macsyma's loading not to work.
∨
Date: 9 NOV 1978 0051-EST
From: MATSON at MIT-MC (Wayne E. Matson)
To: (BUG LISP) at MIT-MC
In trying to use the TOPS-10 version of LISP out here at Marlboro
I have encountered the following difficulties.
Not all fasl files will load. some get "file not in fasl format".
This is similar to a problem I had with LISP 1 1/2 years ago where
it used dump mode i/o to read the fasl file, but if the last IOWD
failed. (last block not full) it assumed that it didn't get
anything where as it really did. jonl said that he fixed this
particular problem, so my guess is probably wrong.
doing i/o in general occasionally gets one of many varied
ill uuo ... type messages from the monitor, or
write into read only memory from lisp. This tends to bring to
mind another old lisp bug where you played around with .jbff
and/or .jbrel before doing the initial "in" or "out" uuo's that
set up the buffer rings. the code that did this assumed that
the monitor would alwasy build a ring of 2 buffers. This is
NOT the case. The number of buffers is related to the cluster
size of the disk. again, Im not sure that this has anything to
do with the problem at hand. I haven't spent enough time
to figure out exactly what's going on.
minor things are
you set up the default ppn from the users ppn, not his path
lisp doesn't understand SFD's. (this is really 2 problems)
You could run lisp out of an sfd if it would put "0" in
the 4th word of the lookup/enter block if a ppn wasn't specified.
since lisp does specify the 4th arg every time, it is impossible
to read a file form an sfd.
full sfd stuff would be nice, and probably wouldn't be very hard...
Ill send more once I get some more time to play with it again.
schedules are getting pretty tight...
∨
RLB@MIT-MC 11/08/78 11:56:52 Re: MACLisp's SKOTT macro
Should be moved from MACS to DEFNS, for .FASL users.
But I didn't take it upon myself to do so.
∨
Date: 7 Nov 1978 1136-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: TSTLSP
To: HIC at SU-AI
I tried out TSTLSP. I did an (edit) which autoloads an editor
and it proceeded to core up to 510p and then halted at 53065. Perhaps
you could explain a bit about the theory behind TSTLSP so that we
can judge what's happening?
-rpg-
∨
gsb@MIT-ML (Sent by KWC@MIT-ML) 11/03/78 15:55:59
To: (BUG LISP) at MIT-ML
(load '(moby file))
..... <grind grind grind>
↑B
;bkpt ↑b
(gc)
$P
MPV; RDCHAR+1>>MOVE B,@RSXTB B/ HLL F,R 276157/ ??
RSXTB/ A,,276117
rdinch/ rdin
Someone not restoring or clobbering or gcing RSXTB?
(A had 40 in it)
∨
GSB@MIT-ML 11/02/78 21:03:45 Re: (sstatus ttycons <sfa> nil)
To: (BUG LISP) at MIT-ML
appears to get arguments identical to
(status ttycons <sfa>)
So how can it tell whether you are reading or clearing it?
∨
GSB@MIT-ML 11/02/78 21:43:33
To: HIC at MIT-ML
Lisp toplevel loop doesn't ask a sfa (which is the value of TYI) for it's
ttycons, to output the terpri...
∨
Date: 1 NOV 1978 1214-EST
From: JONL at MIT-MC (Jon L White)
Subject: Finding out what file (and array) objects exist
To: (BUG LISP) at MIT-MC, rms at MIT-AI, rich at MIT-AI
The tag "GCMKL" in LISP holds a list of arrays in the system;
problem is that this tag is not accessible without loading
the symbol table, so probably there should be some status call,
or some primitive function, which copies the top level of this
list, deleting the "dead-array" markers. If Howard doesn't want
to do it, then I will for the next lisp.
∨
GSB@MIT-ML 11/01/78 12:54:01 Re: GC-OVERFLOW
To: (BUG LISP) at MIT-MC
CC: GSB at MIT-MC
GCOB goes through BKCOM which calls ERRPRINT.
But there is no error frame, so if one is already in a break loop, you get
the previous error message.
∨
Date: 28 Oct 1978 2151-EDT
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Lossages in CMUA MACLISP
To: bug-lisp @ mit-ai
CC: fahlman at CMU-10A, touretzky at CMU-10A
Message-ID: <28Oct78 215125 SF50@CMU-10A>
We are using an internal LISP editor here until such time as we can get an
EMACS/LEDIT system running. In such a system it is inconvenient to have
displace do its thing, since it puts out the expanded form into the edited
source. I can think of other situations in which DISPLACE wants to be
inhibited as well. How about having DISPLACE be a no-op unless the variable
displace is NON-NIL. Most of the old hand-written displace functions had this
feature.
A number of errors punt the user out of LISP and back to the TOPS-10 system.
Two examples are typing alt-P to the PDL-OVERFLOW error handler, which
causes an IRREPARABLE-PDL-OVERFLOW (I know it's stupid, but it's easy to do
by accident) and setting T or NIL, which causes an attempt to write into
read-only memory error, and exits to the system with no intervening break.
When this happens, it should be easy to get back to the top-level of the
existing LISP. It turns out that START does this, but REE or CONTIN flame
out destructively. Is this easy to correct? It is particularly tragic to
flame out a LISP when editing internally, since fuction definitions
representing a lot of work may be lost.
Aside from such minor lossages, we are winning. The active MACLISP
community now stands at four members, Dave McDonald has adapted the
UCI-Lisp editor for MACLISP, and Dave Touretzky has created an init
file and some IO functions which move around nicely through the
cretinous CMU directory structure.
Scott Fahlman
∨
Date: 30 OCT 1978 0228-EST
From: MOON5 at MIT-MC (David A. Moon)
Subject: BUG IN ASSLIS
To: (BUG LISP) at MIT-MC
AT CFDEL+1, THERE IS A RANDOM .FDELE WHICH IS PRESUMABLY
TRYING TO DO A DELETE. ACTUALLY, IT DOES A RENAME DUE TO
A MISSING 0 IN ITS ARGUMENT BLOCK. UP UNTIL JUST NOW, THIS
WAS A LOSS SINCE RENAME ON THE CLU DEVICE CRASHED THE SYSTEM
(WHICH I HAVE FIXED).
∨
jls@MIT-AI (Sent by JOHAN@MIT-AI) 10/30/78 10:48:15
To: (BUG LISP) at MIT-AI
I think it is a bug that LISP rebinds ECHOFILES to NIL
in a breakpoint. It does not rebind MSGFILES or OUTFILES,
why should it rebind ECHOFILES? (It does rebind ↑R to NIL,
which is "ok"). This becomes a problem when dribbling
(e.g. using LIBLSP;DRIBBL). If ECHOFILES were treated the
same as MSGFILES and OUTFILES, then I could win by simply
typing control-R at the breakpoint, but now i have to
fool around with (SETQ ECHOFILES OUTFILES) or some such.
∨
DAVET@MIT-ML 10/29/78 11:46:12
To: (BUG LISP) at MIT-ML
CC: DAVET at MIT-ML
grindef becomes confused on numeric arguments:
it gives, e.g., (SETQ 1 '1) and then hangs somewhere
from whence it must be control-G'ed, and after that
things in general seem to work strangely.
-davet
∨
HIC@MIT-MC 10/29/78 03:00:33
STILL WANT TO BE ABLE TO HAVE UUO LINKS WITHOUT HISEG...LOOK INTO IT
∨
JONL@MIT-MC 10/27/78 15:31:30
To: (BUG NILINT) at MIT-MC
"<" and ">" should admit multiple arguments, unlike maclisp.
Thus, modulo side-effects, (< a b c) should be like
(and (< a b) (< b c))
∨
MOON@MIT-AI (Sent by MOON0@MIT-AI) 10/25/78 11:52:23
To: (BUG LISP) at MIT-AI
I GOT A MPV FROM $DEV1+3 WHILE TRYING TO LOAD UCODE SYMBOLS INTO A
LISP. IT HAD READ THRU 97% OF THE INPUT FILE, AND THERE WAS NOTHING
APPARENTLY STRANGE ABOUT THE INPUT NEAR THAT REGION. THE LOSSAGE WAS
REPRODUCABLE, BUT UNFORTUNATELY, IN THE COURSE OF FURTHER HACKING I
WILL PROBABLY ALTER FILES, ETC, NEEDED TO REPRODUCE IT EXACTLY.
IT WOULD GREATLY HELP TRACK THESE THINGS DOWN IF THERE WERE A SOURCE
OF LISP ON THE MACHINE (IN EMACS-ABLE FORM) AND A TAGS FILE.
∨
GSB@MIT-ML 10/24/78 19:32:24
To: (BUG LISP) at MIT-ML
gc-overflow does an errprint but sets up no error frame.
This is fucking confusing if you are already inside of an error break
loop.
∨
Date: 24 OCT 1978 0147-EDT
From: GSB at MIT-MC (Glenn S. Burke)
To: (BUG LISP) at MIT-MC
Iloprs which get trapped through UUOGLEEP when there is a machine-error
handler loop infinitly, re-trying the losing instruction. It appears
that what is happening is that the bit saying that the error is a machine-error
is not being set in D right before calling UINT in UUOGL2.
(If i single-step through this and set the bit in D, then everything works.)
∨
Date: 19 Oct 1978 1145-PDT
From: Dick Gabriel <RPG at SU-AI>
Subject: NAMESTRING
To: HIC at SU-AI
Is the namestring supposed to have the PPN in it somewhere.
(namestring '((dsk (zte sch)) garb age)) => |dsk:garb.age|.
-rpg-
∨
HIC@MIT-MC 10/19/78 13:55:28
Ok, stuff to do for impure SAIL version:
A) KILHGH, GETHGH
B) LDRIHS
C) All sorts of purification stuff can be completely flushed
∨
Date: 4 Sep 1978 1203-PDT
From: Mclure at SRI-KL (Stuart Cracraft)
Subject: Native mode 20xMaclisp
To: Hic at Mit-MC
I'm interested... heard about it from KLH
-------
∨
FFM@MIT-MC 09/17/78 20:21:28 Re: my address
I have 2 addresses you can use either.
The POBX address is slower but safer than E
Palo Alto address.....
EPA is faster by couple of days but
more danger of stuff getting lost/taken.
adrees in EPA is 395 E'O'Keefe #31
East Palo Alto,CA
94303
Have fun
Sends Steve
∨
Date: 24 Sep 1978 1957-EDT
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: MACLISP
To: HIC at MIT-MC (Howard I. Cannon)
CC: Scott.Fahlman @ CMUA
Message-ID: <24Sep78 195721 SF50@CMU-10A>
In-Reply-To: Howard I. Cannon's message of 24 Sep 78 18:13
Hi, Howard,
Things are going pretty well here, but I haven't been hacking MACLISP much.
Since we have no manual here yet, I have to teach UCI lisp to the new
kiddies, which means I have to learn it myself. An inferior, but usable
product. The strategy for this fall is (1) to get some manuals here, (2) to
create library files for everything that people like about the UCI lisp that
they might want in MACLISP, and (3) to announce the MACLISP here and encourage
everyone to switch to it. Step (4), which might never happen, is to stop
supporting UCI lisp and seize the good words for maclisp: LISP.INI, for
instance, and the .LSP file extension (at present we are stuck with .MCL).
Step 2 is the interesting one. I have imported STEP, #PRINT, REDO, and DEBUG*
from LIBLSP and all work fine except for the EVALHOOK bug that screws STEP
(you got a note on this?). The two things that may be worth stealing from the
present UCI/CMU lisp are a slightly better internal editor and an extensive
HELP facility. There is also a hairy UNDO mode, but I consider the use of
this to be a sign of the moral decline of Western Civilization. The HELP
responds to calls of the form (HELP FOOBAR) and goes off to a disk file
to find the info on FOOBAR. This is printed on the screen, but does not
clutter up the innards of LISP. Both these things are written in LISP, so
can be gobbled easily. I have an undergraduate to work on these things --
Tierney Barron, you may be getting some messages from her once she gets to
work. If we can get the MACLISP manual in on-line form we can carve it into
HELP texts rather easily. I assume that this would be of general interest
and usefulness, so I'll add it to LIBLSP at MIT when it's done.
The EMACS-like editor for the z-80 black-box terminals is coming along,
scheduled for completion by XMAS or so. In lieu of such an editor, we
have to edit files from within LISP using the lisp editor, so a good editor
is fairly important. Once the black-box editor is up -- we're calling it
IGOR after the little guy in the Frankenstein movies who goes off to the
graveyard to fetch pieces of things -- we will want to create some sort of
LEDIT. Tops-10 will fight us on this since it doesn't think that one job
ought to have two processes alive at once, but we'll find a way. One
possibility is to write a version of the PDP-10 side of this editor to
live within MACLISP itself (an autoload, of course) so that editing is
done within the same job. The PDP-10 side is a fairly simple gap editor
like a subset of old teco, so this may not be too hard. All the hairy stuff
happens within the z-80.
Anyway, that's the state of the universe. My immediate wish list for
MACLISP consists of the following:
1. A manual.
2. The new version you mentioned.
3. A fix for the EVALHOOK bug.
4. CMU PPN's
5. Changing the default init file to MACLSP.INI and the default
extension to MCL.
One longer term query: When MACLISP becomes the default LISP here, we would
like people using the COMP CENTER machines (all TOPS-20's) to have access to a
compatible LISP. These machines are not on the net, but I can move a tape.
Is TWENEX MACLISP a stable enough product that such a thing would be likely
to fly without much diddling?
I thank you again for your efforts. Once the "Immigration Course" for new
people ends (start of OCtober), I expect to start MACLISPing in earnest.
Scott
∨
HIC@MIT-MC 09/26/78 14:47:23
Fix STREAM-GET/STREAM-STORE to do appropriate hackery and improve
documentation.
∨
SUN@MIT-ML 10/12/78 08:42:04
To: HIC at MIT-ML
When you send that next LISP, I didn't get the sort package last
time. Also could you tack on the source to Morgenstern's
Stepper, something like mm;mmstep >. The object on liblsp; is non
∨
HIC@MIT-MC 10/17/78 00:18:06
Look into REENTER address going away.
∨
Date: 16 Oct 1978 (Monday) 2217-EST
From: DEWOLF at WPAFB-AFAL
Subject: new lisp for Illinois
To: hic at MIT-ML
Yes, we need a new copy of lisp. The last three we've received
have been unusable for one reason or another. JONL and GLS have
been making up tapes and sending them to use via the USMAIL. We
have just recently been connected to the arpanet thru a dedicated
TTY line to WPAFB-AFAL, but our line is only 1200 baud. This
seems to slow to me to get a new lisp over.
If you could make us a tape and mail it to us it would be
appreciated. JONL could fill you in on the details if you are
not sure what should go on the tape. We have a large MacLISP
community here on our 10 as well as another 10 here on campus.
Mail the tape, if you can, to:
Tim Finin
Coordinated Science Lab
University of Illinois
Urbana, IL 61801
Thanks,
Tim Finin (FININ@MIT-AI)
∨
rms,rich@MIT-AI (Sent by RICH@MIT-AI) 10/16/78 17:32:17
To: (BUG LISP) at MIT-AI
It is so often a problem that people forget about files
which are open in their Lisps, that something should be done about it.
Even people who know that they must put CLOSEs in their code
do this if their functions have bugs and don't reach the CLOSE.
It is just not good enough to rely on people to know that they
should do (GC) in such cases, because inevitably someone will not
have got the word yet and will tie up the system.
Also, they may have put some of their file objects on global vars
so that even (GC) won't close them, and may not be able to remember
what the vars are called or even that they exist.
Clearly Lisp must offer some way for the user to find out what the
status of his disk files is, so that he can close them.
There should be a function which prints out a description of
which channels have which files open, and another which allows
the user to close specific channel numbers. Or maybe the first
one should, after printing the list, ask about each file whether
to close it. A simpler alternative might be to return a list of
the open file-objects (dug up from a non-GC'd variable inside Lisp)
but that has the problem of making lost objects be pointed to again,
so you might not like it. Also, the former is more likely to be
used, actually, by not-so-experienced people, so I prefer it.
It is important to do something.
∨
MOON@MIT-AI 09/23/78 05:31:33
To: (BUG LISP) at MIT-AI
When it erases the ##MORE##, it should position the cursor at the front of
the ##MORE## rather than the front of the line. For instance, when the gc
prints a ";adding a new list segment..." message on the bottom line of the
screen, the ##MORE## comes out at the end of that line since interrupts
are cretinously deferred during the printing of this message, and when the
more is proceeded, the gc message gets erased.
∨
Date: 14 Oct 1978 2029-PDT
From: Dick Gabriel <RPG at SU-AI>
Subject: READ6C
To: HIC at SU-AI
The table FLSYMS appears no to be defined in newio,
and I assume that none of those labels are available from faslap?
READ6C is a valuable symbols for the compiler to know about,
otherwise my code needs (DEFSYM ...)'s all over the place.
-rpg-
∨
Date: 14 Oct 1978 2034-PDT
From: Dick Gabriel <RPG at SU-AI>
Subject: RENAMEF
To: HIC at SU-AI
Doesn't seem to try hard enough. If you try to rename to
a file that already exists, then it barfs. OR, COMPLR should delete
the file before the renamef in the case of fasl files.
-rpg-
∨
Date: 14 Oct 1978 2036-PDT
From: Dick Gabriel <RPG at SU-AI>
Subject: FASLOAD
To: HIC at SU-AI
Direct.fas[aid,rpg] which was just produced by COMPLR 836
is "not in fasload format".
-rpg-
∨
Date: 14 Oct 1978 2048-PDT
From: Dick Gabriel <RPG at SU-AI>
To: HIC at SU-AI
EOPEN should do a SHOWIT UUO.
∨
GSB@MIT-ML 10/13/78 22:55:31 Re: ttyscan
To: hic at MIT-MC
1) The toplevel loop does not ask my sfa for ttycons.
2) If it did it would die, because my sfa doesn't know how to do that.
3) The reason it doesn't know how to do that is because the relationship
wouldn't be symetrical, because i can't make a sfa the ttycons of a file.
4) Pushj p,opntty kills the lisp [my tty-return handler did this if it
changed consoles, but it had a bug making it think it was always changing
consoles!] However, this is probably an indication that suspending the
lisp won't work very well.
5) (status tty) loses.
6) (status ttycons tyi) loses.
7) (status ttyint) loses.
8) (status ttyscan) loses BADLY. (NIL UNDEFINED FUNCTION IN UUO CALL -
this probably means it got an ilopr or something...)
Undoubtedly the same is true for doing output, even ignoring the gc.
(eg, (status ospeed), ttysize,.....
∨
Date: 13 Oct 1978 1613-PDT
From: Dick Gabriel <RPG at SU-AI>
Subject: 2 minor requests:
To: BH at SU-AI, HIC at SU-AI
1. Could you set up ↑g to quit as well as ↑G? I think all this is
is a change to fb.buf table in *lisp?
2. Could you have ↑Z put you in DDT (again in fb.buf?)
3. The instant macro stuff?
Thanks.
-rpg-
∨
Date: 13 Oct 1978 1630-PDT
From: Dick Gabriel <RPG at SU-AI>
Subject: NEWIO/Compiler
To: HIC at SU-AI, JONL at SU-AI
1. What's the new way to save away a complr now that cdump isn't around?
2. Can the toplevel reader use EREAD?
3. I can't get the compiler to compile anything!
r newcom
LISP COMPILER 834 [BY 834]demon.gc(kt)
←demon.gc(t)
Compilation begun on (DEMON GC DSK (AID RPG))
(COMMENT **** ((TOPFN) (FILEPOS . 2560.))
Lisp Error during file compilation)
;BKPT LISP-ERROR
Any help will be appreciated.
-rpg-
∨
Date: 13 Oct 1978 1651-PDT
From: Dick Gabriel <RPG at SU-AI>
Subject: Complr bug
To: HIC at SU-AI
NEWCOM was made with ncompl.ini[new,lsp]
-rpg-\
∨
Date: 12 OCT 1978 1829-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
LISP 1753 bombs out trying to fasload the complr at CMU
I ftp'd LISP;RELRLQ 1753, and suitably lost. Furthermore, the
autoload properties are automatically being set to the SYS device -
I thought there would be a way to rearrange that?
∨
GSB@MIT-ML 10/09/78 19:37:31
To: (BUG LISP) at MIT-ML
In newio, LAP should NOT bind ↑W and ↑R to nil when it prints its loading
message, it should print it to MSGFILES.
∨
DDM@MIT-AI 10/09/78 19:48:49
To: (BUG LISP) at MIT-AI
Why is it that:
(hunkp (makhunk (list 'foo nil))) = NIL ????
I.e. why are two item hunks (or perhaps its 2 item hunks where item2= nil)
not hunks as far as hunkp is concerned ????
∨
GSB@MIT-ML 10/06/78 22:04:48
To: (BUG LISP) at MIT-ML
(setq foo (array nil t 10.))
#T-12-70776
(arraycall nil foo 2 3)
;((NIL . 2) (NIL . 777776)) TOO MANY ARGUMENTS SUPPLIED - APPLY
Where is all the error info disappearing to???
∨
HIC@MIT-MC 09/19/78 23:24:01
look into bug whereby throw nil nil does
not find the frame in:
(*catch 'foo (unwind-protect (progn (print 'foo) (throw nil nil)) (print 'bar)))
∨
Date: 5 Oct 1978 2001-EDT
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Re: MACLISP for CMUA
To: HIC at MIT-MC (Howard I. Cannon)
Message-ID: <05Oct78 200119 SF50@CMU-10A>
In-Reply-To: Howard I. Cannon's message of 5 Oct 78 01:46
Howard,
Just saw your second message. The PPN's and MACLSP.INI file are important,
the latter since we cannot use an INIT file to set it. The default file
extension, the ↑H for RUBOUT, and the various autoload pointers we can do
within the INIT file, so you needn't bother. I guess for the sake of
efficiency we should have the switch to use line-read mode in TOPS-10
(what was it called?) on as a default, and people can turn it off if they
want at init time. That's all I can think of for now, but there will
probably be some more things as the user community grows.
Scott
∨
GSB@MIT-ML 09/27/78 21:42:54
To: (BUG LISP) at MIT-ML
hey, i thought the lossage of having somethin like P.≠X to a lisp
waiting for input had been fixed? Upon ≠P'ing it i get a .value
at uintpu...
(note the presence of a tty-return interrupt which does next to nothing)
∨
GSB@MIT-ML 09/30/78 23:55:49
To: (BUG LISP) at MIT-ML
-1←-1 => ;ILLEGAL OBJEXT SOMEWHERE OR OTHER - READ
rather than either /-1←-1 or 377777777777
∨
Date: 26 SEP 1978 0131-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
(quit 't)
fails to be "noiseless", and per documentation in LISP NEWS
∨
HIC@MIT-MC 09/14/78 11:20:21
Ability to take channel interrupts
∨
Date: 8 SEP 1978 2137-EDT
From: RLB at MIT-MC (Richard L. Bryan)
Subject: Pooooor reader!
To: (BUG LISP) at MIT-MC
(sstatus + t) (setq ibase 16.)
'-eof-
gives ";ILLEGAL OBJECT SOMEWHERE OR OTHER - READ"
instead of /-EOF- . By the way, '/-EOF- prints without slashifying the
leading -.
∨
Date: 31 Aug 1978 2315-PDT
From: GLS at SU-AI (Guy Steele)
Subject: SAIL NEWIO and SHOWIT
To: BUG-LISP at MIT-MC
The SHOWIT uuo should be applied to the UREAD channel
whenever UREAD is done. It should be applied to
the UWRITE channel by UWRITE iff no UREAD channel
is active.
∨
Date: 26 Aug 1978 1812-EDT
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: MACLISP init files
To: hic @ mit-mc
Message-ID: <26Aug78 181231 SF50@CMU-10A>
Hi, Howard,
Next time you're changing the CMUA MACLISP, we would like to have the
default init file name changed to MACLSP.INI . Unfortunately, we are
going to have to co-exist for a while with the old UCI lisp which is
known around here simply as LISP and which looks for a file named LISP.INI.
Some users have already tripped over this as they tried to play with the
new MACLISP. (Fear not, I have not yet advertised it to random users, but
some of the local LISP-hackers have wanted to try MACLISP, understanding
that it is not yet a certified product.) As always, if there are problems with
this let me know and we can think up some other solution.
Scott
∨
Date: 24 AUG 1978 0837-EDT
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC
I notice that (CHARPOS T) does not return the "real" position if ↑W is T (i.e.
suppose you typed ↑W at the left margin. (CHARPOS) says, correctly, that
your hpos is 2. Then type a RETURN, whose echoing puts you at hpos=0.
(CHARPOS T) still thinks it is 2). Is this a feature or a bug?
∨
Date: 22 Aug 1978 1042-PDT
From: RPG at SU-AI (Dick Gabriel)
To: hic at MIT-MC
Could you have UREAD (OPEN) do a SHOWIT UUO?
Here's the specs.
Thanks. -rpg-
SHOWIT [OP=047, ADR=400011] CALLI 400011
--------------------------------------------------
MOVEI AC,<flags + I/O channel number>
SHOWIT AC,
The SHOWIT UUO causes your job's wholine to include a display of the status of a
disk (DSK or UDP) file on the right half of the 3rd line of the screen (the left
half of the 3rd line is never touched by the wholine). SHOWIT can also be used
to turn off the file-status display. The form of the file-status display is
FILENM EXT PRJPRG LENGTH USETP MODES
where the first three of these give the file's name, extension and PPN; LENGTH
is the file's length in (octal) records; USETP is the current (octal) value of
the USET pointer for the file; and in the MODES, U means the file is on a UDP, R
means the file is being Read, RA means the file is open in Read-Alter mode, W
means the file is being Written, and E means the End of file has been reached.
Upon call, AC should contain the I/O channel number whose disk file status is to
be displayed (unless you are turning off the display) plus any of the flags in
the following table.
BITS OCTAL MEANING OF FLAG IN SHOWIT UUO
18 0,,400000 Suppress the erasure of the file-status display that
normally happens when the I/O channel being displayed
is released or when the file-status display is turned
off. This is useful if your program normally displays
something else on that line which you don't want the
system to erase. This bit is irrelevant if the display
is a III.
19 0,,200000 Don't display any file status on the wholine. This
turns off any previous file-status display (whether
turned on by UUO or by keyboard command).
∨
Date: 21 Jul 1978 1520-PDT
From: WP at SU-AI (Wolfgang Polak)
Subject: Interpreted SUBRCALL
To: bug-lisp at MIT-MC
The code at PTRCHK: should in the D10 version account for
the possible existence of a high-segment BPS.
-- GLS
-------
∨
MOON5@MIT-AI 07/20/78 01:46:09
To: (BUG LISP) at MIT-AI
Once again I was screwed by a function declared to return fixnum
that didn't, and therefore didn't get its first instruction executed,
causing mysterious bugs that took hours to track down. When is Lisp
going to detect this error? (It is trivial to detect).
∨
JONL@MIT-MC 07/12/78 12:05:22
To: HIC at MIT-MC
CC: GLS at MIT-MC, JONL at MIT-MC
did you ever write a replacement for FLSASS INFO, the documentation
file for ASSLIS that used to be on my directory?
∨
RLB@MIT-MC 07/10/78 21:31:29 Re: GETDDTSYM
(1) Generalize GETDDTSYM to accept (and just return) fixnums.
(2) If it can't get the symbol, rather than FAIL-ACT with ARGS bound
to (GETDDTSYM <the losing symbol, unquoted>), do WRNG-TYPE-ARG with
ARGS being bound to the losing symbol (actually, ncons of it). Then
to recover, the luser can load symbols and do (return args). If
some other number is desired, then do (return '(<number>))) to win
in all cases.
∨
Date: 5 JUL 1978 2041-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Simplifications for UUO links etc.
To: (BUG LISP) at MIT-MC
2) According to GSB, the UUO clobberer should bypass the clobbering
on any binary-program page which is considered pure. There is come
code in the UUO handler which tries to decide whether or not to
clobber - perhaps we could merely extend it to inspect the GCST for
the page in question, and it it is alleged to be pure, then cancel.
∨
HIC@MIT-MC 07/01/78 19:22:22
Don't forget to fix defaultf problem for Tops-20. Store the default
name into PNBUF then use NAMESTRING-->'sixbit' stuff (or use GTJFN and
JFN-->'sixbit' stuff) etc..
∨
HIC@MIT-MC 06/29/78 09:46:00
Think about zero pages not being saved problem for Tops-20.
∨
PUCK@MIT-MC 06/07/78 17:27:46
look into why gc-lossage can't be recovered -- also
better definition of GC parameters.
ERRPRINT with second arg.
∨
ββ